The Design and Long-Term Use of a Personal Electronic Notebook: A Reflective Analysis

Thomas Erickson

Advanced Technology, Apple Computer, Inc.

ABSTRACT

This article describes the design and use of a personal electronic notebook. The findings provide a useful data point for those interested in the issue of how to design highly customizable systems for managing personal information. After a description of the notebook's interface and the usage practices that have co-evolved with the interface, I discuss some of the features which have made the notebook useful over the long term, and trends in the evolution of its design.

Keywords

Electronic notebooks, personal information management, customization, tailoring, longitudinal study, reflective analysis, co-evolution of design and practice

INTRODUCTION

Personal electronic notebooks pose an interesting challenge for designers and developers. A general design problem is discovering how to make something useful, as opposed to just usable. This problem is particularly acute for systems like electronic notebooks that support the capture, use, and management of personal information. Unlike conventional applications such as word processors or spreadsheets, a notebook is very personal: it only becomes useful over time-months or years-as it becomes the repository of more and more personally relevant information. While it is straightforward to study usability-that is, how easy it is to learn and use various features of the notebook-it is much more of a challenge to understand which features, and which modes of use, would make such a notebook useful.

Proteus

Several years ago I participated in a project that involved the design of a working prototype of a personal notebook. As noted above, while it is easy to study the usability of such a notebook, it is more difficult to understand which features would contribute to its usefulness over the long term. In this case, fragility of both the software and hardware prototypes frustrated any attempts at longitudinal evaluation.

One approach is to study how people manage their personal information today. In fact, we began our project by looking at how people used artifacts such as notebooks, calendars, post-it notes, and computers. This proved to be a rich source of ideas, and particularly drove home the point that different people did very different things. But it doesn't fully address the question. An electronic device for managing personal information will have properties that are very different from those of paper-based artifacts, and will therefore be used in different ways. So, the question remains: how can we learn about the ways in which an electronic personal information manager will really be used over a long period of time?

My response was to build my own electronic notebook, which I refer to as Proteus. My original intent was to force myself to use it on a daily basis for two months, keep track of how it evolved to support my work practices, and to make note of its benefits and drawbacks. Proteus turned out to be sufficiently useful that little discipline was required to accomplish this. As of this writing I've been using Proteus on a daily basis for three years. The occasional periods when I am forced to do without it because of mechanical or logistical problems reveal that it has become the primary tool by which I manage my work and professional life.

In more objective terms, Proteus is a HyperCard®-based application that is designed for use on a PowerBook®. In terms of content, Proteus consists of approximately 1500 pages of personally meaningful information, collected over the course of five years (some preexisting information was imported into Proteus). In terms of technology, Proteus is a collection of 9 HyperCard stacks taking up about 6 megabytes of disk space; it consists of about 80 handlers, and a few commonly available X-commands.

A Note on Method

While I have drawn upon a number of sources of data for this account-a change diary I kept about modifications to Proteus and the rationale behind them, archives of notebook versions and their contents, and an automatically- generated log of notebook commands-the fact remains that this is essentially a subjective account of my experience. Where possible, I have used analysis of portions of the notebook contents and the command log to confirm basic facts such as the approximate frequency of usage. But this has not revealed any surprises. The most interesting aspects of this account-claims about why certain features succeeded or failed, what accounts for the notebook's usefulness, the co- evolution of work practice and functionality-can not be verified by analyzing command logs or content.

Objections to this approach to exploring design issues include concerns about subjectivity, and the lack of generality of any findings. While I do not contest these objections-indeed, they are quite reasonable-I would note that no method is so sound as to allow designers to confidently proceed from the findings of one or even a few studies done within its scope. I believe that the sort of reflective analysis exemplified by this paper is well-suited to the inherently personal nature of this topic. Reflective analysis can yield much of value if it is carried out carefully, and if designers also draw upon other methodologies to inform their work.

What's Next?

I begin with an overview of the Proteus interface, and then discuss the ways in which I actually use Proteus. Finally I describe some of the lessons I've learned from this experience. Throughout this paper I maintain a deliberately casual, first-person style, as a reminder that the findings being described are based on a population of one.

AN OVERVIEW OF THE INTERFACE

It is difficult to describe Proteus because it has changed over time. What I'll do is describe the interface as it was in June 1994; at that time, most of the features discussed had been stable for about a year.

Proteus can be thought of as a series of notebooks. There is a primary notebook called the "working notebook" that is almost always open. In addition, a "bookshelf" menu gives access to secondary notebooks (e.g., a notebook of reading quotations, working notes for 1993, etc.) and reference stacks (e.g., a company phone directory).

Notebooks contain two types of pages: content pages where notes are made, and table of contents (TOC) pages which provide structural overviews of the notebook.

Content Pages

A content page contains four areas (figure 1):

Header area. The top portion of the page has several fields for header information such as the name of the notebook section and subsection, the date the page was started, and so on.

Content area. This is a single scrolling field where almost all information is entered.

Page-Specific Controls. Below the content field is a series of buttons for commands which apply to the content area. The page-specific controls appear to be on the same background as the content and header areas.

Global Controls. Below the page-specific controls, on a darker graphic background, are controls which support global commands-primarily commands for navigating around the notebook.

Table of Contents (TOC) Pages

The other type of page is the table of contents page (TOC)-it provides structural overviews of the notebook or parts of the notebook. The structure of the notebook is quite simple: it is divided into sections, the sections are divided into subsections, and the subsections consist of pages. Each level of hierarchy has its own TOC page. That is, there is a global TOC for the whole notebook, and there are separate TOCs for each section and for each subsection. Typically, a TOC will only show the next lower level in the hierarchy, although this can be overridden. The TOC for a subsection will show the first line from the content area of each of its content pages.

The Global TOC

The global TOC (figure 2) has browser-like properties: selecting a section name from one of the upper panes in the window will show a list of its subsections (and sometimes subsection contents) in the lower pane. Clicking on any item in the lower pane will take you to that page.

ection and Subsection TOCs

The section and subsection TOCs are simply lists of their contents. The section TOC contains a list of subsections, and the subsection TOC contains a list of pages (where each page is represented by the first line of its contents). Clicking on any item in the TOC will take you to the appropriate page. Figure 3 shows an example of a subsection TOC (the "May '94" subsection of the "Daily Notes" section ). (Over time a convention has evolved of summarizing a content page's important entries on its first line, enabling the TOC page to function as a sort of abstract or summary of its subsection.)

Accessing Functionality

Most of the functionality of Proteus is accessed through page-specific and global controls arrayed along the bottom of the page. Page-specific controls (see figure 1) typically act on the contents of a page, and are used for common actions such drawing a dashed line to separate entries, prepending selected lines of text with >'s (for preparing responses to email), and turning selected lines of text into an email message.

Global controls are for navigating around the notebook, or for altering the notebook's structure. Examples of global controls include buttons for jumping to the global TOC, today's notes page, and the next section, as well as buttons searching, creating stamps, and making new pages.

Other mechanisms for accessing functionality include a "Bookshelf" menu for navigating between notebooks, and key shortcuts for commonly done actions (e.g., hide notebook; jump to Finder; go to next page).

HOW I USE PROTEUS

Proteus evolved to support me, and therefore it is appropriate to say a few words about my inclinations and activities before describing how I use Proteus. As with the interface description, I focus on the period centered on June, 1994, when my job had been stable for about a year, and my commuting situation had been stable for about three months.

Context

My work situation in June, 1994, was that I was part of a small, 3 person group located in Cupertino, California. My activities involved communicating closely with my colleagues, and with groups scattered across the organization. I was involved-at least at a peripheral level-in many tasks at once. In general, my roles included acting as a researcher, designer, strategist, and consultant.

I commute to my California office from Minnesota, flying in for one week a month. The week that I'm in town is focused on meetings-approximately a dozen formal (scheduled) meetings, and lots of informal visits and hallway conversations. When I work from my Minnesota office, I attend one or two meetings a week by phone, but focus more on tasks like reading, writing, and analysis. At the time being discussed, I sent perhaps 10 email messages a day, and received about 30 (the majority not personally addressed to me), regardless of geographic location.

In general, I am a very text-oriented person with a variety of interleaved, on-going activities. I read a lot, and write a lot. Writing includes papers, email, and notes about meetings, projects and design issues. In a very real sense writing is my way of thinking about things: I work out ideas and their implications in the process of making notes, writing email, and authoring papers.

Daily Use as a Work Diary

The principle function of Proteus is as a work diary. I use it to maintain a To Do list, to keep notes on meetings, to compose and send email, and as a repository for information (e.g., email messages) on which I want to reflect or act later on. I keep all the information for a day on one page in a long scrolling field (see figure 4).

I've developed a fairly consistent daily routine for using Proteus:

I begin by going to the page of the day.

I update the To Do list at the top of the page (usually, the To Do list for that day has already been started).

I switch out of Proteus and check my email and calendar. This may result in further additions to the To Do list. Email that has content that I want to save or that I want to reflect on and answer later, may be pasted into the content area.

As the day goes on I usually have Proteus near at hand. I will use Proteus to update my To Do list, to jot brief notes (e.g. telephone messages; thoughts), and to compose and send email. When in meetings, I will usually make notes in Proteus; if the meeting is fairly large and is covering matters that don't concern me, I'll make notes on other things, update my To Do list, or do email, while monitoring what's going on in the meeting.

So, in summary, frequent uses of Proteus (ranging from once or twice a week to many times a day) include:

Managing my tasks (To Do'ing)

Recording meeting notes

Messaging

Serving as a repository for information

Occasional Use for Reference and Summaries

I use Proteus for a number of other tasks, although their frequency is in the range of from once a week to once a month. These include:

Reference. I use the search command to search through Proteus for information several times a month- occasionally a particular quotation from something I've read, more often notes from a particular meeting.

Summarization. Once a month I do a report on my activities; this involves browsing the last month's worth of Proteus entries. Occasionally, I need to produce a summary of the results of a series of meetings, and will search for notes relevant to particular projects.

Diagramming. A couple times a month I will use Proteus to draw diagrams or models relevant to meetings or projects in which I'm evolved. (This is a completely unanticipated use: I hadn't imagined that anyone-let alone me-would want to draw with a track ball!)

Capturing Reading Notes. If I read something useful, I'll often transcribe quotations from it into a special section of Proteus. This activity occurs in bursts-with several months intervening between bursts.

Ways in Which I Don't Use Proteus

It is interesting to note that I do not use Proteus in the way I originally thought I would. The motivation behind transforming Proteus from a stack of quotations into a full-featured electronic notebook was the vision of being able to make notes for a paper, and link the notes to the relevant quotations. However, after finishing the work of programming Proteus, I quickly abandoned this use. I found that jumping to the quotations caused a disruptive context shift, and that the functionality provided by HyperCard text fields was insufficient. What I really wanted (and soon switched to) was an outliner into which I could copy my quotations, and where I could interleave them with notes and writing fragments. In general, I do not use Proteus to author structured documents.

Usage of Proteus versus Paper Notebooks

Before Proteus I was a heavy user of paper notebooks. As with Proteus, I used paper notebooks as a sort of work diary: I started each day on a new page, kept a To Do list, meeting notes, and used it as a repository for other information. However, there are couple of striking differences (besides the obvious one that I didn't use it for composing email). First, I find that I make many more notes in Proteus-in part this is because I find typing easier and faster than writing, and in part because of synergetic effects I describe in the next section. Second, I rarely looked back through my paper notebooks-and when I did, I only tended to look at recent entries. In contrast, I re-read entries in Proteus frequently. There are several reasons for this: it is easier to search and browse; the content is more legible; and when I find something useful it can be copied and re-used.

LESSONS LEARNED

Contributions to Usefulness

Although there are many ways in which Proteus is quite useful, two are so important as to make it an essential part of my work activity.

Synergy

Probably the most significant impact of Proteus is a sort of synergy among the activities of note making, reference, and messaging. Messaging drives this synergy. I write notes more often-and my notes are of higher quality-because I know that I am more likely to email them to others. Because the quality of my notes is higher, I reference (and reuse) them more when I'm writing a relevant message or paper. Also, the increased quality means that I am more likely to understand them when I look back at them after six months. In turn, the increased frequency of reference also drives note making and messaging: the more use I get out of them, the more effort I'm willing to put into them. Thus, there is a curious sort of ambiguity when writing in Proteus: my proximate goal may be keeping notes on an interesting meeting, but I also know in the back of my mind that they may also turn into a message or serve as grist for a future paper.

Context Independence

The other major aspect of Proteus' usefulness has to do with its portability, and with the amount of personally relevant information in it. I typically carry Proteus with me and so I always have a variety of tasks of various sizes that I can work on. If I arrive at a meeting early, I can compose a message, review notes, or update my To Do list while waiting for others to arrive.

This has changed my behavior. I am more willing to go to large meetings where some or all of the content is of unknown relevance: if the meeting is relevant, I pay attention and take notes; if parts are irrelevant, I can work on other things while keeping half an ear on the meeting. I have had extremely productive work sessions when 'stuck' in the middle of a row in the auditorium. While this may sound like a small thing, the degree to which it alleviates irritation at late-starting meetings, and anxiety about being stuck in irrelevant meetings, makes a significant difference in my life.

Finding Things

Although note making, messaging, and activity management are the primary uses of Proteus, information storage and retrieval plays an important role in supporting these tasks, as well as being useful independently. Proteus supports a variety of ways of searching for things. One can use text search, browse using the section and subsection TOCs, or search for items that have been specially marked in various ways.

Text Search

One of the putative benefits of an electronic notebook is that you can use text search. This is not as useful as it might seem. There are three problems: First, a fact of life for me, and I suspect for most electronic notebook users, is that notes are written hastily, and hence contain frequent misspellings, typos, and abbreviations. Thus, standard keyword searches are not very effective in finding words which have been mistyped or hastily abbreviated. Second, I use many words much more frequently than I'm aware of. Words like object, metaphor, interface, and communications are so frequent as to not be worth searching for, as are common project names. In this respect the use of To Do lists is a drawback, as important projects and items tend to recur in To Do lists and generate hit after hit when searching. Finally, the limitations of HyperCard's search mechanism (it takes you to the card, and shows only the first word of the first instance that matches) exacerbates the above problems. A search mechanism that would generate a list of fuzzy hits (so that when searching for PowerTalk, you'd also get PowerTlk, and PwerTalk), shown with surrounding context, would be far more useful.

As a consequence of this, text search in Proteus is primarily useful when: 1) trying to put together a summary of what has happened on a project (i.e., many hits are just what you want); 2) when searching for a relatively unique target that is probably spelled correctly (e.g., part of an email address string such as "boombox"; or 3) when the approximate location of the item is known, so that the search can be limited to that neighborhood.

Marking

A second strategy for finding is to mark things when you think you may want to find them later. Proteus provides two mechanisms for this: stamps and dog-ears. A stamp is a way of providing a sort of topic-specific book mark- Proteus had stamps for addresses, reference citations, and 'interesting items.' The user can select a type of stamp and can then jump from one stamp to the next. Dog-ears are similar to stamps except a bit simpler: they are the analog of folding over the corner of a page. Like stamps, the user can jump from one dog-ear to the next.

I use dog-ears several times a month; however, I rarely use stamps. One reason for this has to do with overhead. While stamps are easy to use, requiring no more than a click to stamp something, if I'm engaged in my current activity I don't think about the desirability of stamping the item, or if I do, I often don't want to interrupt my flow of activity. If I do decide to interrupt myself, I still tend not to use stamps. Stamps are primarily a way of deferring actions until later: I stamp addresses so I can enter them in my address file; I stamp citations so I can put those in a special place; and so on. If I decide to interrupt my activity, I typically just go ahead and do the whole thing.

However, this doesn't explain why dog-ears are used so much more frequently than stamps, since they are logically and functionally equivalent, both requiring a click to create, and both requiring clicking a button to search for. I believe that the explanation is that stamping something seems to require more cognitive overhead. In stamping something, the user is basically making the decision to apply a particular label to a particular piece of content. In contrast, marking a page with a dog-ear is simply saying 'I may want to look at something on this page again.' Dog-ears are more light weight than stamps.

Browsing

Proteus succeeds best at search by browsing. That is, a common strategy for finding something-if its approximate location is known-is to browse the appropriate table of contents. I may recognize what I'm searching for, and can then jump directly to it. Or I may see something which reminds me of the context, and thus generates more cues about what I'm searching for. The decision to include the first line of each content page in the subsection TOCs turned out to be a good one.

(Of course, it should be noted that TOCs were not designed with this use in mind. TOCs evolved in the context of the original quotations stack (see next subsection), and the idea of using the first line of each page was derived from an analogy to the indices of poetry and quotation anthologies.)

Evolution of the Design

One interesting facet of Proteus is that it has changed considerably over time, both in terms of its underlying structure and function, and in how it was used.

The Pre-History of Proteus

Proteus did not spring into existence as an electronic notebook, or as a vehicle for exploring issues about customization and long term usefulness. Rather, it went through a gradual evolution.

Proteus began as a stack of quotations and notes (my practice is to copy down quotes from favorite books or articles). After a year or so, I had enough entries that using them became cumbersome, and so I added a table of contents that could be recompiled when new quotations were added. As more cards were added it became desirable to break it into subsections and to have a hierarchical table of contents.

About this time, I realized that with 'just a little more work' I could have an electronic notebook that would allow me to explore on a personal level some of the frustrating issues already described. I also had a concrete task in mind for Proteus: I had been wanting to write a paper that drew upon a number of the quotations I had collected in the stack, and I thought it would be very useful to be able to outline the paper, and link parts of it to relevant quotations.

From Linking/Authoring to Messaging and Note Making

Personal electronic notebooks have a paradoxical aspect to them: they really don't become useful until considerable material has been entered, and yet how many people will exert the effort needed to enter material, before the utility is evident? I call this the start up problem. While it is dangerous to generalize from a population of one, the case of Proteus suggests an interesting answer to the start up problem.

Initially, Proteus tried to solve the start up problem by cheating, in that it began with a large number of quotations that had been gradually built up over a couple of years. However, this failed, in that the initially envisioned authoring/linking use for Proteus didn't pan out: it was too cumbersome. Instead, what saved Proteus from being abandoned was its use as a diary, and that in turn was driven by the incorporation of messaging functionality. Messaging added collaborative value to the note making functionality of Proteus, and permitted it to be useful (and encouraged the entry of information), until there was enough information to make Proteus useful for reference purposes.

(As in the case of TOCs, the full importance of messaging was not anticipated. Messaging was originally incorporated in Proteus only because it was easy to add. I already had an X-command and script for messaging that I had used in another stack, the electronic edition of a newsletter I edit. Ironically, messaging was a failure in that context; fewer than a dozen people ever made use of it.)

Increasing Structure

When working on the predecessor to Proteus (the original, working prototype of an electronic notebook), I had a running debate with another designer over how much structure people wanted in an electronic notebook. What I wanted, I claimed, was something very simple: just a temporally-ordered set of pages. People remember things by time, I said, and if you allow them to move pages around, and create sections, they'll just start losing things, and we'll have to introduce all sorts of functionality for organizing and navigating the notebook.

As Proteus evolved, it quickly became apparent that I was wrong. While I don't find it surprising when my intuitions about what other people want are wrong, I was surprised to discover that my intuitions about what I wanted were wrong. But it's incontestable. The most obvious trend in the evolution of Proteus is the gradual addition of more and more layers of structure. Proteus started out as one notebook; after a bit it was broken into sections, each with their own table of contents. After a bit longer subsections and subsection TOCs were added. And finally major sections of the notebooks were broken apart into separate notebooks which can be accessed through a bookshelf menu.

At the same time, it is important to note that at the beginning I neither wanted nor needed the structure. It was only as time went on, and I added more and more information, and begin to develop specialized ways of interacting with it, that the increased structure became useful for supporting access and browsing, and for segregating functionality.

Increasing Specialization

This brings us to the next trend in the evolution of Proteus: the increasing degree of task-specific specialization. As I began using Proteus in new ways, after a while I would develop functionality that support the new mode of use. For example, the use of Proteus as a diary started out fairly simply: text was simply entered onto a blank, unspecialized content page. But as time went on I developed various conventions, and then eventually implemented functionality to support and reinforce those conventions. Some instances:

The diary page begins with the date. Initially the date was entered manually. After a while, I created a "header" button to automatically generate the date for the day. As of this writing, the working notebook for a new year is generated, with the diary pages having the date embedded in them.

As the To Do list became more heavily used, buttons that supported particular operations on it appeared (e.g., a 'procrastinate button', that moves selected To Do items to tomorrow's page; a 'to do button' that copies selected text (usually from notes), and inserts it in the To Do list.)

A convention of separating different items with dashes was codified with the "---" button, which automatically drew a line of dashes.

These are all minor things. However, they do use up significant amounts of the limited space for controls, and contribute to the transformation of pages in the "daily notes" section from generic content pages to diary-specific pages. The appearance of task-specific controls also increased the pressure to split off the diary portion of the notebook into its own notebook. Perhaps most importantly, the appearance of task-specific functionality resulted in new structural features of the notebook which could then be used to support the development of more task-specific functionality. For example, once the "---" button for separating items was implemented, it was easy to create a button to jump from one item to the next because the system could tell that a new item was marked by the appearance of a particular number of dashes; prior to that, when dashed separators were generated manually and might have any number of dashes, the task of writing a script to distinguish separators from other uses of dashes was more work than seemed justified.

Similar stories can be told about other uses of Proteus. The quotation reference section of Proteus became more specialized, and was split off into its own notebook. A section of Proteus that started out to support scheduling, gradually became more complex and specialized, until it was replaced with links to an external, calendar application. The global Table of Contents began as a regular TOC (as in figure 3), and only gradually developed the browser-like structure shown in figure 2. Again and again there was a move from generality and simplicity towards specialization and complexity. And while there are many instances of periods of simplification (e.g., the removal of unused functionality), these simplifications were often triggered by the desire to make room for new functionality.

rom Generic and Usable to Arcane and Useful

When I began using Proteus, I had a relatively simple application that was easy to use and to explain to others. Now, Proteus is much more complex; it has quite a few features that are useful only to me, and that make the interface more complex and difficult to learn for anyone else. In the process of being customized for my purposes, Proteus has shifted from being usable (by anyone) to being useful (to me).

This raises some interesting questions. How general is this tradeoff between simplicity and usability on the one hand, and specialization and complexity on the other? Will technologies like OpenDoc, which promise to support customization, manifest this trend? Or, less generally, suppose that three years ago I had been magically given Proteus as it is structured today: would I have found it either usable or useful? I suspect the answer is no. My guess is that my work practices had to gradually evolve in consonance with the structure and function of Proteus. That is, rather than this being a process of me gradually customizing Proteus to my needs, it feels more like a process of co-evolution in which the electronic notebook and my work practices have mutually conditioned one another. For example, as previously noted, the use of Proteus resulted in me being more willing to attend large meetings, and in turn, more frequent use of Proteus in large meetings resulted in various adaptations for more effective use in such situations (e.g., an easy way to turn the sound off).

On Customizability

It's important to note that Proteus evolved only because HyperCard provided such a flexible and readily-customizable environment. Three things seem of importance. First, the ability to change small things-graphics, buttons, handlers-made Proteus feel like a truly malleable environment. It got me into the habit of tweaking things. Another important factor was the availability of modules of functionality that could be imported from elsewhere. Scripts created both by myself and by others were often incorporated into Proteus. This greatly decreased the overhead involved in adding functionality, and made it much easier to experiment. For example, it took me less than twenty minutes from conception to working implementation to add voice notes into Proteus (and this is fortunate because I never used them). Finally, the aforementioned context independence provided by Proteus also applied to its customization. That is, at any time I encountered a problem or thought of a way Proteus could be tuned to better support my practices, I could do it. A number of small but important features were implemented while waiting for people to show up, or while 'stuck' in large meetings. This practice was so prevalent during the early stages of developing Proteus, that I built in a special command key combination to jump into the HyperTalk Reference stack.

CONCLUDING REMARKS

There are a number of reasons Proteus is a useful tool for me. One is simply that it supports the representations with which I work. Proteus is good at dealing with text, and many of the ways in which I reflect, communicate, and act, are entwined with textual representations. A person for whom other representations of information were more critical, would probably not find Proteus a useful tool.

Finally, the fact that the portability of Proteus enables me to perform many tasks-reflection, communication, activity management-anywhere, has proved to be very useful. While this result was by no means unanticipated, the second order effects such as my increased willingness to attend large meetings were not expected.

Proteus is also interesting as an illustration of evolution through customization. Over the course of three years Proteus exhibited consistent trends towards specialization, task-specific functionality, and greater complexity. In addition, there was a pronounced tendency for Proteus and my work practices to co-evolve-it seems doubtful that starting out with the final version of Proteus would have been useful.

Finally, there are striking parallels between the design of Proteus, and design in the large. Common beliefs about designing products for users-that designers' intuitions aren't to be trusted, that designers are poor at predicting how a technology will be used, that iteration is an inherent part of design, that features will be used in unanticipated ways, that users are poor at articulating what they really need-carry over even to the case where the designer and the user are one.

ACKNOWLEDGMENTS

Thanks to a number of anonymous reviewers for suggestions and comments.

HyperCard, Newton, and PowerBook are registered trademarks of Apple Computer. The Virtual Notebook System is a trademark of Baylor College of Medicine and the ForeFront Group. Lotus Notes is a registered trademark of Lotus Development Corporation. Wizard is a registered trademark of Sharp.

REFERENCES

1. Assimacopoulos, A., Revillard, C., Herrmann, F., Borst, F., Paschoud, N. and Scherrer, J. R. An Electronic Notebook for Problem Oriented Patient Progress Notes: Testing a Concept. Proceedings of the 6th Annual Conference on Medical Informatics (1989), pp. 813-817.

2. Conklin, J. and Begeman, M. L. gIBIS: A Hypertext Tool for Exploratory Policy Discussion. Proceedings of CSCW '88 , (1988), ACM Press.

3. Dejan, D. and Dejan, S. B. Lotus Notes at Work. Lotus Books, New York, 1991.

4. Fowler, J., Baker, D. G., Dargahi, R., Kouramajian, V., Gilson, H., Long, K. B., Petermann, C., and Gorry, A. G. Experience with the Virtual Notebook System: Abstraction in Hypertext. Proceedings of CSCW '94. (1994). ACM Press, pp. 133-143.

5. Halasz, F., Moran, T. P., and Trigg, R. H. NoteCards in a Nutshell. Proceedings of CHI + GI 1987 (1987), ACM Press, pp. 45-52.

6. John-Steiner, V. Notebooks of the Mind: Explorations of Thinking. Harper & Row, New York, 1985.

7. Monty, M. L. Issues for Supporting Notetaking and Note Using in the Computer Environment. (1990) Unpublished Dissertation, Department of Psychology, University of California, San Diego.

8. Monty, M. L. and Moran, T. P. A Longitudinal Study of Authoring Using NoteCards. SIGCHI Bulletin 18, 2 (1986), pp. 59- 60.

9. Neuwirth, C., Kaufer, D., Chimera, R., and Gillespie, T. The Notes Program: A Hypertext Application for Writing from Source Texts: Experiences and Writing. Proceedings of the Hypertext '87 Conference, (1987), ACM Press, pp. 121-141

10 Schnase, J. L. and Leggett, J. J. Computational Hypertext in Biological Modeling Applications. Proceedings of the Hypertext '89 Conference, (1989), ACM Press, pp. 181-197.

11 Shipman, F. M., Chaney, R. J., and Gorry, G. A.. Distributed Hypertext for Collaborative Research: The Virtual Notebook System. Proceedings of the Hypertext '89 Conference, (1989), ACM Press, pp. 129- 135.

12 Trigg, R. H. and Irish, P. M. Hypertext Habitats: Experiences of Writers in NoteCards: Proceedings of the Hypertext '87 Conference, (1987), ACM Press, pp. 89-108

13 Twidale, M., Rodden, T., and Sommerville, I. The Designers' Notepad: Supporting and Understanding Cooperative Design. Proceedings of the Third European Conference on Computer-Supported Cooperative Work (1993), pp. 93-107.